The Java 2 Platform, Enterprise Edition (J2EE) is a software standard for developing multitier enterprise applications. The J2EE architecture has a client tier, middle tier, and back-end tier. The client tier supports a variety of client types, and the middle tier supports client services and business logic through web and Enterprise Java Beans (EJB) containers in the middle tier. The back-end tier includes the Enterprise Information Systems (EIS) in the EIS tier and many standard Application Programming Interfaces (APIs) for accessing databases. An Enterprise Information System is generally any kind of computing system that offers high quality of service, deals with large volumes of data and capable of supporting some large organization (“an enterprise”). One of skill in the art can accordingly alter the objects and components resident on the several tiers. “Containers” are standardized runtime environments that provide services to components on the platform. All containers provide runtime support for responding to client requests and returning results to clients. The containers also provide APIs to support user session management.
Resident within the J2EE architecture is a “resource adapter” that plays a central role in the integration and connectivity between an EIS and an application server (software framework dedicated to the efficient execution of procedures for supporting the construction of applications) and serves as the point of contact between application components, application servers and enterprise information systems. A resource adapter and other components, must communicate with one another based on a standard referred to as the J2EE Connector Architecture (JCA). To enable seamless integration with an application server, the resource adapter abides by system-level “contracts” defined by the JCA. These contracts exist between the application server and the EIS, and are implemented through the resource adapter. The contracts specify how a system external to the J2EE platform integrates with it by supporting basic functions handled by the J2EE container. There are three major contracts: the “connection management contract” which allows applications to connect to an EIS, and enables the application server to utilize pooling (pooling of resource connections); the “transaction management contract” which allows an application server to manage and perform transactional access across one to many EIS resource managers; and the “security contract” which provides support for secure access to the EIS.
As discussed above, the connection management contract allows the application server to pool resource connections. In connection with pooling resource connections, an object, commonly referred to as a connection factory, creates the resource connections to a resource (e.g., database) based on the properties configured on the connection factory instance.
Applications running by an EIS system (e.g., tax collection application, online banking application) may service different number of requests during different times of the day and therefore need a different number of resource connections to a database (resource) to store or retrieve data in connection with servicing these requests. For example, suppose a tax collection application is used to collect tax information from individuals and corporations on behalf of the government. The tax collection application is busy at the end of the work day between 4:00 pm-6:00 pm and also at the end of the month (e.g., 29th, 30th and 31st day) as tax submissions peak at this time. At peak time, this application requires more than 100 connections to the database (resource) to be available for the requests to be serviced. Normally, during non-peak times, the application needs an average of 30-40 connections to the database. Hence, in order to ensure that there are enough connections to the database (resource) during any particular time, the administrator configures the connection factory to create a maximum pool size of 100 connections. In case there are more than 100 concurrent users accessing the tax collection application, they would have to wait for free connections to become available.
Furthermore, suppose a second application, an online banking application, uses a separate connection pool to access the same database (resource). The online banking application is busy from 9:00 am-4:00 pm on Monday through Friday, and especially busy during 9:00 am-1:00 pm (peak-time), where 250 connections to the database are required to service the requests. However, if the database can only handle 300 connections concurrently, then the administrator configures the connection factory to create a maximum pool size of 200 connections for this application. Hence, during the peak-time, the online banking application would not be able to service all the requests concurrently.
However, during 9:00 am-4:00 pm on Monday through Friday (except the last few days of the month), the tax collection application only needs an average of 30-40 connections to the database. Hence, it has about 60-70 connections unused during that time since it is allocated 100 connections to the database to service requests. As a result, the resource connections are not being optimally utilized. The online banking application users will have to wait until the connections are released in order to be served despite the fact that tax collection application has about 60-70 connections unused during the time that the online banking application could use additional connections.
While an administrator may attempt to manually reconfigure the size of the connection pool for the applications, such as reducing the size of the connection pool for the tax collection application and increasing the size of the connection pool for the online banking application, applications may unpredictably receive an increase in the number of requests to be serviced, including for the application whose pool of connections was reduced, and therefore, may no longer be able to service all the requests concurrently.
Hence, there is not currently a means for efficiently utilizing the resource connections in the connection pools.